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USING A HIGH LEVEL PROGRAMMING processing 16, 32, or 64 bits of information or more with a 
LANGUAGE WITH A MICROCONTROLLER single instruction. In contrast to the microprocessor, a micro- 
controller includes a central processing unit, memory and 
Under 35 U.S.C. § 119(c), this application claims benefit other functional elements, all on a single semiconductor 
of prior U.S. provisional application Serial No. 60/029,057, S substrate, or integrated circuit (e.g., a "chip**). As compared 
filed Oct. 25, 1996. to the relatively large extemal memory accessed by the 
A portion of the disclosure of this patent document microprocessor, the typical microcontroller accesses a much 
contains material which is stibject to copyright protection. smaller memory. Atypical microcontroller can access one to 
The copyright owner has no objection to the facsimile sixty-four kilobytes of built-in memory, with sixteen kilo- 
reproduction by anyone of the patent document or the patent lO bytes being very common. 

disclosure, as it appears in the Patent and Trademark OfiScc There are generally three different types of memory used: 

patent file or records, but otherwise reserves all copyright random access memory (RAM), read only memory (ROM), 

rights whatsoever. and electrically erasable programmable read only memory 

„ „ ,^„r^.™^^T (EEPROM). In a microcontroller, the amount of each kind 

BACKGROUND OF THE INVENTION ,5 memory available is constraia^d by the amo.mt of space 

This invention relates in general to the field of on the integrated circuit used for each kind of memory, 

programming, and more particularly to using a high level Typically, RAM takes the most space, and is in shortest 

programming language with a smart card or a microcontrol- supply. ROM takes the least space, and is abundant, 

ler. EEPROM is more abundant than RAM, but less than ROM. 

Software applications written in the Java high-level pro- ^ Each kind of memory is suitable for different purposes, 
gramming language have been so designed that an apphca- Although ROM is the least expensive, it is suitable only for 
tion written in Java can be run on many different computer data that is unchanging, such as operating system code, 
brands or computer platforms without change. This is EEPROM is useful for storing data that must be retained 
accomplished by the following procedure. When a Java when power is removed, but is extremely slow to write, 
application is written, it is compiled into "Class" files ^ RAM can be written and read at high speed, but is expensive 
containing byte codes that are instructions for a hypothetical and data in RAM is lost when power is removed A micro- 
computer called a Java Virmal Machine. An implementation processor system typically has relatively little ROM and 
of this virtual machine is written for each platform that is EEPROM, and has 1 to 128 megabytes of RAM, since it is 
supported. When a user wishes to run a particular Java not constrained by what will fit on a single integrated circuit 
application on a selected platform, the class files compiled device, and often has access to an external disk memory 
from the desired application is loaded onto the selected system that serves as a large writable, non-volatile storage 
platform. The Java virtual machine for the selected platform area at a lower cost than EEPROM. However, a microcon- 
is run, and interprets the byte codes in the class file, thus troller typically has a small RAM of 0.1 to 2.0 K, 2K to 8K 
effectively running the Java application. of EEPROM, and 8K-56K of ROM. 

Java is described in the following references which are Due to the small number of extemal components required 

hereby incorporated by reference: (1) Arnold, Ken, and and their small size, microcontrollers frequently are used in 

James Gosling, "The Java Programming Language," integrated circuit cards, such as smart cards. Such smart 

Addison-Wesley, 1996; (2) James Gosling, Bill Joy, and Guy cards come in a variety of forms, including contact-based 

Steele, "The Java Language Specification," Sua cards, which must be inserted into a reader to be used, and 

Microsystems, 1996, (web site: http://java.sun.com/doc/ contacUess cards, which need not be inserted. In fact, 

language__specificatioD); (3) James Gosling and Henry microcontrollers with contactless communication are often 

McGilton, "The Java Language Environment: A White embedded into specialized forms, such as watches and rings, 

Paper," Sun Microsystems, 1995 (web site: bttp:// effectively integrating the functionality of a smart card in an 

java.sun.com/doc/language_environraent/); and (4) Tim ergonomically attractive manner. 

Lindholm and Frank Yellin, "The Java Virmal Machine Because of the constrained environment, applications for 

Specification," Addison-Wcsley, 1997. These texts among smart cards are typically written in a low level programming 

many others describe how to program using Java, language (e.g., assembly language) to conserve memory. 

In order for a Java application to run on a specific The integrated circuit card is a secure, robust, tamper- 
platform, a Java virtual machine implementation must be 50 resistant and portable device for storing data. The integrated 
written that will run within the constrainU of the platform, circuit card is the most personal of personal computers 
and a mechanism must be provided for loading the desired becatise of its small size and because of the hardware and 
Java application on the platform, again keeping within the software data security features unique to the integrated 
constraints of this platform. circuit card. 

Conventional platforms that support Java are typically 55 The primary task of the integrated circuit card and the 

microprocessor-based computers, with access to relatively microcontroller on the card is to protect the data stored on 

largearaountsof memory and hard disk storage space. Such the card. Consequently, since its invention in 1974, inle- 

microprocessor implementations frequently are used in grated circuit card technology has been closely guarded on 

desktop and personal computers. However, there are no these same security grounds. The cards were first used by 

conventional Java implementations on microcontrollers, as go French banks as debit cards. In this application, before a 

would typically be used in a smart card. financial transaction based on the card is authorized, the card 

Microcontrollers differ from microprocessors in many user must demonstrate knowledge of a 4-digit personal 

ways. For example, a microprocessor typically has a central identification number (PIN) stored in the card in addition to 

processing imit that requires certain extemal components being in possession of the card. Any information that might 

(e.g., memory, input controls and output controls) to func- 65 contribute to discovering the PIN number on a lost or stolen 

tion properly. A typical microprocessor can access from a card was blocked from public distribution. In fact, since 

megabyte to a gigabyte of memory, and is capable of nobody could tell what information might be useful in this 
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regard, virtually all information about integrated circuit high level languages sucb as Java and Eiffel, using powerful 

cards was withheld. mainstream program development tools. New applications 

Due to the concem for security, applications written for <imckly prototyped and downloaded to a smart card 

integrated circuit cards have unique properties. For example, » ^ours wjlhout resorting to soft masks. Embed- 

each application typically is idenUfied with a particular S f ed systems using mi«ocontrollers can also pn many of 

owner or idenUly. Because appUcations typically aJe written f«=^ "dv^Uges for downloading new apphcauons. high 

, , ' . L LI level program development, and rapid prototyping by mak- 

m a low.lcvcl programmmg language, such as assembly ■ ^ invention. 

language the applicauot^ are wntten for a pam^^^ Implementations of the invention may include one or 

rmcrocontrollcr. Due to the nature of low level programmmg ^^^/^^ foUowing. TTie high level programming lan- 

languages, unauthonzed apphcaUons may access daU on the 10 ^^^^^ application may have a class file format 

mtegrated circuit card. Programs wntten for an mtegrated ^^^y ^^^^ ^ j^^^ programming language format. The 

circuit card are identified with a particular identity so that if processor may be a microconiroUer. At least a portion of the 

two identities .want to perform the same programming memory may be located in the processor. 

function there must be two copies of some portions of the application may have been processed from a second 

application on the microcontroller of the integrated circuit 15 ^ppUcation that has a string of characters, and the string of 

card. characters may be represented in the first application by an 

Integrated circuit card systems have historically been identifier (e.g., an integer). 

closed systems. An integrated circuit card contained a dedi- The processor may be also configured to receive a request 

catcd application that was handcrafted to work with a from a requester (e.g., a processor or a terminal) to access an 

specific terminal application. Security checking when an ^ element (e.g., an application stored in the memory, data 

integrated circuit card was used consisted primarily of stored in the memory or the communicator) of the card, after 

making sure that the card application and the terminal receipt of the request, interact with the requester to authcn- 

application were a matched pair and that the data on the card ^^a^^ an identity of the requester, and based on the identity, 

was valid selectively grant access to the element. 

c . , , J • '4 A 4^ The memory may also store an access control list for the 

As the popularity of integrated circmt cards grew, it , *Tn. *ir*A-u -j *- c 

, It..- . J - J ij i_ clement. The access control list furnishes an indication or 

became clear that integrated circmt card users would be ^^^^^^^ ^ ^^^^^ ^ . ^^^^ 

averse to carrying a different integrated circuit card for each ^^^^ ^^^^^^ ^^^^ processor selectively grants specific 

mtegrated circuit card apphcaUon. Therefore, muluple coop- jyp^^ ^^^^ ^^^^ing data, writing daU, appending 

crating applications began to be provided on single provider 3^ (jata, creating data, deleting data or executing an appbcation) 

integrated circuit cards. Thus, for example, an automated |q requester. 

teller machine (ATM) access card and a debit card may -j^^ appUcation may be one of a several applications 
coexist on a single integrated circuit card platform. stored in the memory. The processor may be further con- 
Nevertheless, this was still a closed system since all the figured to receive a request from a requester to access one of 
applications in the terminal and the card were built by one the plurality of applications; after receipt of the request, 
provider having explicit knowledge of the other providers. determine whether said one of the plurality of applications 

The paucity of information about integrated circuit complies with a predetermined set of rules; and based on the 

cards — particularly information about how to communicate determination, selectively grant access to the requester to 

with them and how to program them — has impeded the said one of the plurality of applications. The predetermined 

general application of the integrated circuit card. However, 40 rules provide a guide for determining whether said one of the 

the advent of public digital networking (e.g., the Internet and plurality of applications accesses a predetermined region of 

the World Wide Web) has opened new domains of applica- the memory. The processor may be further configured to 

tion for integrated circuit cards. In particular, this has lead to authenticate an identity of the requester and grant access to 

a need to load new applications on the card that do not have said one of the plurality of applications based on the identity, 

explicit knowledge of the other providers, but without the 45 The processor may be also configured to interact with the 

possibility of compromising the security of the card. terminal via the communicator to authenticate an identity; 

However, typically, this is not practical with conventional determine if the identity has been authenticated; and based 

cards that are programmed using low level languages. on the determination, selectively allow communication 

, between the terminal and the integrated circuit card. 

SUMMARY OF THE INVENTION THe communicator and the teriiinal may communicate 

In general, in one aspect, the invention features an inle- via communication channels. The processor may also be 

grated circuit card for use with a terminal. The integrated configured to assign one of the communication chaimels to 

circuit card includes a memory that stores an interpreter and the identity when the processor allows the communication 

an application that has a high level programming language between the terminal and the integrated circuit card. The 

format. A processor of the card is configured to use the 55 processor may also be configured to assign a session key to 

interpreter to interpret the application for execution and to the assigned communication charmel and use the session key 

use a communicator of the card to communicate with the when the processor and the terminal communicate via the 

terminal. assigned communication channel. 

Among the advantages of the invention are one or more The terminal may have a card reader, and the commuoi- 
of the following. New applications may be downloaded to a 60 cator may include a contact for communicating with the card 
smart card without compromising the security of the smart reader. The terminal may have a wireless communication 
card. These applications may be provided by different com- device, and the communicator may include a wireless trans- 
pan ies loaded at different times using different terminals. ceiver for communicating with the wireless communication 
Security is not compromised since the applications are ^ device. The terminal may have a wireless communication 
protected against unauthorized access of any application 65 device, and the communicator may include a wireless trans- 
code or data by the security features provided by the Java mitter for communicating with the wireless communication 
virtual machine. Smart card applications can be created in device. 
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In general, in another aspect, the invention features a municate with the terminal and a memory that stores a first 

method for use with an integrated circuit card and a terminal. application that has been processed from a second applica- 

The method includes storing an interpreter and at least one cion having a string of characters. The string of charaaers 

application having a high level programming language for- arc represented in the first application by an identifier. The 

mat in a memory of the integrated circuit card. A processor s integrated circuit card includes a processor that is coupled to 

of the integrated circuit card uses the interpreter to interpret the memory. The processor is configured to use the intcr- 

ihe at least one application for execution, and the processor preter to interpret the first application for execution and to 

uses a communicator of the card when communicating use the communicator to communicate with the terminal, 

between the processor and the terminal. [n general, in another aspect, the invention features a 

In general, in another aspect, the invention features a 10 method for use with an integrated circuit card and a terminal, 

smart card. The smart card includes a memory that stores a The method indudes processing a second application to 

Java interpreter and a processor that is configured to use the create a first application. The second application has a string 

interpreter to interpret a Java application for execution, of characters. The string of characters is represented by an 

In general, in another aspect, the invention features a identifier in the second application. An interpreter and the 

microcontroller that has a semiconductor substrate and a first application arc stored in a memory of the integrated 

memory located in the substrate. A programming language circuit card, A processor uses an interpreter to interpret the 

interpreter is stored in the memory and is configured to first application for execution. 

implement security checks. A central processing unit is In general, in another aspect, the invention features a 

located in the substrate and is coupled to the memory. microcontroller that includes a memory which stores an 

Implementations of the invention may include one or ^ application and an interpreter. The application has a class file 

more of the following. The interpreter may be a Java byte format. A processor of the microcontroller is coupled to the 

code interpreter. The security checks may include establish- memory and is configured to use the interpreter to interpret 

ing firewalls and may include enforcing a sandbox security Ibe application for execution. 

model. In implementations of the invention, the microcontroller 

In general, in another aspect, the invention features a also include a communicator that is configured to 

smart card that has a programming language interpreter communicate with a terminal. 

stored in a memory of the card. The interpreter is configured In general, in another aspect, the invention features a 

to implement security check. A central processing imit of the method for use with an integrated circuit card. The method 

card is coupled to the memory. includes storing a first application in a memory of the 

In general, in another aspect, the invention features an integrated circuit card, storing a second application in the 

integrated circuit card that is used with a terminal. The card memory of the integrated circuit card, and creating a firewall 

includes a communicator and a memory that stores an that isolates the first and second applications so that the 

interpreter and first instmctioos of a first application. The second apptication cannot access either the first application 

first instructions have been converted &om second instruc- 35 or data associated with the first application, 

tions of a second application. The integrated circuit card In general, in another aspect, the invention features an 

includes a processor that is coupled to the memory and is integrated circuit card for use with a terminal. The integrated 

configured to use the interpreter to execute the first instruc- circuit card includes a commimicator that is configured to 

tions and to communicate with the terminal via the com- communicate with the terminal, a memory and a processor, 

mimicator. 40 The memory stores applications, and each application has a 

Implementations of the invention may include one or high level programming language format. The memory also 
more of the following. The first and/or second applications stores an interpreter. The processor is coupled to the memory 
may have class file format(s). The first and/or second and is configured to: a.) use the interpreter to interpret the 
applications may include byte codes, such as Java byte apptications for execution, b.) use the interpreter to create a 
codes. The first instructions may be generalized or renum- 45 firewall to isolate the applications from each other, and c.) 
bcred versions of the second instructions. The second use the communicator to communicate with the terminal, 
instructions may include constant references, and the first Other advantages and features will become apparent from 
instructions may include constants that replace the constant the following description and from the claims, 
references of the second instructions. The second instruc- 
tions may include references, and the references may shift 50 ^^^^^ DESCRIPTION OF THE DRAWING 
location during the conversion of the second instmctions to pjo. 1 is a block diagram of an integrated card system, 
the first instructions. The first instructions may be rehnked 2 is a flow diagram illustrating the preparation of 
to the references after the shifting. The first mstructions may j^^^ applications to be downloaded to an integrated circuit 
mclude byte codes for a first type of vu-tual machme, and the ^^^^ 

second instructions may include byte codes for a second 55 ^ . . , , r.. j . . . 

type of virtual machine. The first type is different from the ^ ™- ^ a block diagram of the files used and generated 

second type. converter. 

In general, in another aspect, the invention features a /I^;. ^ ^ ^ block diagram Ulustrating the transformation 

method for use with an integrated circuit card. Hie metiiod apphcaUon class file(s) into a card class file, 

includes converting second instructions of a second appli- 60 ^ ^ diagram illustrating the working of the 

cation to first instructions of a first apptication; storing the *^^ass file converter. 

first instructions in a memory of the integrated circuit card; FIG. 6 is a flow diagram illustrating the modification of 

and using an interpreter of the integrated circuit card to the byte codes. 

execute the first instmctions. FIG. 7 is a block diagram illustrating the transformation 

In general, in another aspect, the invention features an 65 of specific byte codes into general byte codes, 

integrated circuit for use with a terminal. The integrated FIG. 8 is a block diagram illustrating the replacement of 

circuit card has a communicator that is configured to com- constant references with constants. 
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FIG. 9 is a bbck diagram ilhistraling the replacement of communicator 12b, The terminal conmiunicator tUy is a 

references with their updated values. commxmications device capable of establishing a commu- 

FIG. 10 is a block diagram illustrating renumbering of nications channel between the inte^atcd drcuil card 10 and 

original byte codes terminal 14. Some communication options include con- 

HG. U is a block diagram illustrating translation of ' ^^^^^^ communications via radio fre- 

original byte codes for a different virtual machine architec- ^^^^^^ ^^^^^ techniques, seria communication 

protocols, packet communication protocols, ISO 7816 com- 

,^ . , ^- M, , J' munication protocol, to name a few. 

FIG. 12 IS a block diagram illustratmg loadmg applica- ^ . , ^> , • . ■ . ... 

tions into an integrated circuit card. ,„ . ^"""^ 14 can also interact with appLcatoia run- 

.7 . . ^" nmgm the mtegratedcu-cuit card 10. In some cases, different 

FIG. 13 is a block diagram lUustratmg exccuUng appli- terminals may be used for these purposes. For example, one 

cations m an mtegrated circuit card. ^^^^^ p^^p^^ applications, 

FIG. 14 is a schematic diagram illustrating memory different terminals could be used to download the 

organization for ROM, RAM and EEPROM. applications, and yet other terminals could be used to run the 

FIG. 15 is a flow diagram illustrating the overall archi- various applications. Terminals can be automated teller 

tecture of the Card Java virtual machine, machines (ATMs), point-of-sale terminals, door security 

FIG. 16 is a flow diagram illustrating method execution in systems, toll payment systems, access control systems, or 

the Card Java virttial machine with the security checks. any other system that commimicatcs with an integrated 

no. 17 is a flow diagram illustrating byte code execution „ ^"^^^ °' microcontroller 

in the Card Java virtual machine. integrated circuit card 10 contains a card Java virtual 

no. 18 is a flow diagram illustrating method execution in "^^^^^^ (^^^ \l ^PP^" 

the Card Java virtual machine without the security checks. contained on the card 10. 

FIG. 19 is a block diagram iUustrating the association , Referring to HG^ 2, the Java applicadon Mud^^^^ 

between card applications and identities. 25 ^'^^"^^ h ^i"""" ' h ' 

. . . . ^ 20c. These source code files are prepared and compiled m a 

no. 20 is a block diagram illustrating the access rights of j^^^^ application development environment 22. When the 

a specific runnmg appUcaUon. j^^^ application 20 is compiled by the development envi- 

FIG. 21 is a perspective view of a microcontroller on a ronment 22, application class files 24 are produced, with 

smart card. these class files A^class 24fl, B.class 246, and C.class 24c 

FIG. 22 is a perspective view of a microcontroller on a corresponding to their respeaive class Java source code 20fl, 

telephone. 20fe, and 20c. The application class files 24 follow the 

FIG. 23 is a perspective view of a microcontroller on a standard class file formal as documented in chapter 4 of the 

key ring ^^^^ virtual machine specification by Hm Lindholm and 

FIG. 24 is a perspective view of a microcontroller on a 35 .{"^ ^^J^j"' Machine Specification," 

Addison-Weslcy, 1996. These appucation class files 24 are 

. ^ . . fed into the card class file converter 26, which consolidates 

FIG, 25 is a perspective view of a microcontroller on a compresses the files, producing a single card class file 

cu-cuit card of an automobile. 27. The card class file 27 is loaded to the integrated circuit 

DETAILED DESCRIFHON OF TOE 40 ^^'^ "^^^'1°'''^ T"! 

PREFERRED EMBODIMENTS Referrmg to FIG. 3, the card class file converter 26 is a 

class file postprocessor that processes a set of class files 24 

Referring to FIG. 1, an integrated circuit card 10 (e.g., a that arc encoded in the standard Java class file format, 

smart card) is constructed to provide a high level, Java- optionally using a string to ID input map file 30 to produce 

based, multiple application programming and execution a Java card class file 27 in a card class file format. One such 

environment. The integrated circuit card 10 has a commu- card class file format is described in Appendix A which is 

nicator 12a that is configured to communicate with a ter- hereby incorporated by reference. In addition, in some 

minal communicator 12 of a terminal 14. In some embodiments, the card class file converter 26 produces a 

embodiments, the integrated circuit card 10 is a smart card string to ID output map file 32 that is used as input for a 

with an 8 bit microcontroller, 512 bytes of RAM, 4K bytes subsequent execution of the card class file converter, 

of EEPROM, and 20K of ROM; the terminal communicator in some embodiments, in order for the string to ID 

12b is a conventional contact smart card reader; and the mapping to be consistent with a previously generated card 

terminal 14 is a conventional personal computer running the class file (in the case where multiple class files reference the 

Windows NT operating system supporting the personal same strings), the card class file converter 26 can accept 

computer smart card (PC/SC) standard and providing Java previously defined string to ID mappings from a string to ID 

development support. input map file 30. In the absence of .such a file, the IDs are 

In some embodiments, the microcontroller, memory and generated by the card class file converter 26. Appendix B, 

communicator are embedded in a plastic card that has which is hereby incorporated by reference, describes one 

substantiaUy the same dimensions as a typical credit card. In possible way of implementing and producing the string to ID 

other embodiments, the microcontroller, memory and com- i°P^t niap file 30 and string to ID output map file 32 and 

municator are mounted within bases other than a plastic illustrates this mapping via an example, 

card, such as jewelry (e.g., watches, rings or bracelets), Referring to FIG. 4, a typical application class file 24fl 

automotive equipment, telecommunication equipment (e.g., includes class file information 41; a class constant pool 42; 

subscriber identity module (SIM) cards), security devices class, fields created, interfaces referenced, and method infor- 

(e.g., cryptographic modules) and appUances. mation 43; and various attribute information 44, as detailed 

The terminal 14 prepares and downloads Java applica- in aforementioned Java Virtual Machine Specification, Note 

tions to the integrated circuit card 10 using the terminal that much of the attribute information 44 is not needed for 
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ihis embodimeat and is eliminated 45 by the card class file 
converter 26. Eliminated attributes include SourceFile, 
ConstantValuc, Exceptions, LincNumberTabIc, 
LocalVariableTable, and any optional vendor attributes. The 
typical card class file 27 as described in Appendix A is 
derived from the application class files 24 in the following 
manner. The card class file information 46 is derived from 
the aggregate dass file information 41 of all application 
class files 24fl, 24b, and 24c. The card class file constant 
pool 47 is derived from the aggregate class constant pool 42 
of all application class files 24a, 24b, and 24c. The card 
class, fields created, interfaces referenced, and method infor- 
mation 48 is derived from the aggregate class, fields created, 
interfaces referenced, and method information 43 of aU 
application class files 24fl, 24b, and 24c. The card attribute 
information 49 in this embodiment is derived from only the 
code attribute of the aggregate attribute information 44 of all 
application class files 24fl, 24fc, and 24c. 

To avoid dynamic linking in the card, all the information 
that is distributed across several Java class files 24a, 24b, 
and 24c that form the application 24, are coalesced into one 
card class file 27 by the process shown in the flowchart in 
FIG. 5. The first class file to be processed is selected 51a. 
The constant pool 42 is compacted Sib in the following 
manner. All objects, classes, fields, methods referenced in a 
Java class file 24fl are identified by using strings in the 
constant pool 42 of the class file 24fl. The card class file 
converter 26 compacts the constant pool 42 found in the Java 
class file 24a into an optimized version. This compaction is 
achieved by mapping all the strings found in the class file 
constant pool 42 into integers (the size of which is micro- 
controller architecmre dependent). These integers are also 
referred to as IDs. Each ID uniquely identifies a particular 
object, class, field or method in the application 20. 
Therefore, the card class file converter 26 replaces the 
strings in the Java class file constant pool 42 with its 
corresponding unique ID. Appendix B shows an example 
application HelloSmartCard.java, with a table below illus- 
trating the IDs corresponding to the strings foimd in the 
constant pool of the class file for this application. The IDs 
used for this example are 16-bit unsigned integers. 

Next, the card class file converter 26 checks for unsup- 
ported features 51c in the Code attribute of the input Java 
class file 24a. The Card JVM 16 only supports a subset of 
the full Java byte codes as described in Appendix C, which 
is hereby incorporated by reference. Hence, the card class 
file converter 26 checks for unsupported byte codes in the 
Code attribute of the Java class file 24a. If any unsupported 
byte codes are found 52, the card class file converter flags an 
error and stops conversion 53. The program code fragment 
marked "A" in APPENDIX D shows how these spurious 
byte codes are apprehended. Another level of checking can 
be performed by requiring the standard Java development 
environment 22 to compile the application 20 with a '-g' 
flag. Based on the aforementioned Java virtual machine 
specification, this option requires the Java compiler to place 
information about the variables used in a Java application 20 
in the LocalVariableTable attribute of the class file 24a. The 
card class Ole converter 26 uses this information to check if 
the Java class file 24fl references data types not supported by 
the Java card. 

Next, the card class file converter 26 discards all the 
unnecessary parts 51c of the Java class file 24fl not required 
for interpretation, A Java class file 24a stores information 
pertaining to the byte codes in the class file in the Attributes 
section 44 of the Java class file. Attributes that are not 
required for interpretation by the card JVM 16, such as 
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SourceFile, ConstantValue, Exceptions, LineNumberTable, 
and LocalVariableTable may be safely discarded 45. The 
only attribute that is retained is the Code attribute. The Code 
attribute contains the byte codes that correspond to the 
methods in the Java dass file 24a. 

Modifying the byte codes 54 involves examining the 
Code attribute information 44 for each method in the class 
file, and modifying the operands of byte codes that refer to 
entries in the Java class file constant pool 42 to reflect the 
entries in the card class file constant pool 47. In some 
embodiments, the byte codes are also modified, as described 
below. 

Modifying the byte codes 54 involves five passes (with 
two optional passes) as described by the flowchart in FIG. 6. 
The original byte codes 60 are found in the Code attribute 44 
of the Java class file 24fl being processed. The first pass 61 
records all the jumps and their destinations in the original 
byte codes. During later byte code translation, some single 
byte code may be translated to dual or U-iple bytes. FIG. 7 
illustrates an example wherein byte code ILOAD_0 is 
replaced with two bytes, byte code ILOAD and argument 0. 
When this is done, the code size changes, requiring adjust- 
ment of any jump destinations which arc affected. Therefore, 
before these transformations are made, the original byte 
codes 60 are analyzed for any jump byte codes and a note 
made of their position and current destination. The program 
code fragment marked "B" in Appendix D shows how these 
jumps are recorded. Appendix D is hereby incorporated by 
reference. 

Once the jumps are recorded, if the optional byte code 
translation is not being performed 62, the card class file 
converter 26 may proceed to the third pass 64. 

Otherwise, the card class file converter converts specific 
byte codes into generic byte codes. Typically, the translated 
byte codes are not interpreted in the Card JVM 16 but are 
supported by converting the byte codes into equivalent byte 
codes that can be interpreted by the Card JVM 16 (see FIG. 
7). The byte codes 70 may be replaced with another seman- 
tically equivalent but different byte codes 72. This generally 
entails the translation of short single specific byte codes such 
as ILOAD_0 into their more general versions. For example, 
ILOAD_0 may be replaced by byte code ILOAD with an 
argument 0. This translation is done to reduce the number of 
byte codes translated by the Card JVM 16, consequently 
reducing the complexity and code space requirements for the 
Card JVM 16. The program code fragment marked "C* in 
Appendix D shows how these translations are made. Note 
that such translations increase the size of the resulting byte 
code and force the r6<omputation of any jumps which are 
affected. 

In the third pass 64, the card class file converter rebuilds 
constant references via elimination of the strings used to 
denote these constants. FIG. 8 shows an example wherein 
the byte code LDC 80 referring to constant "18" found via 
an index in the Java class file 24a constant pool 42 may be 
translated into BIPUSH byte code 82. In this pass the card 
class file converter 26 modifies the operands to all the byte 
codes that refer to entries in the Java class file constant pool 
42 to reflect their new location in the card class file constant 
pool 47. FIG. 9 shows an example wherein the argument to 
a byte code, INVOKESTAHC 90, refers to an entry in the 
Java class file constant pool 42 that is modified to reflect the 
new location of that entry in the card class file constant pool 
47, The modified operand 94 shows this transformation. The 
program code fragment marked "D" in Appendix D shows 
how these modifications are made. 
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Once the constant references are relinked, if the optional ating system 122. In the preferred embodiment, the boot- 
byte code modification is not being performed, the card class strap loader is written in Java, and the integrated circuit card 
file converter may proceed to the fifth and final pass 67. 10 includes a Java virtual machine to nm this application, A 

Otherwise, the card class file converter modifies the Java implementation of the loading a^^^ 

original byte codes into a different set of byte codes sup- 5 120 is ilhistrated ^ Appendix E which is hereby incoipo. 

^ . , , , t_ • J rated by reference. The loading and execution control 120 

ported by Ihe particular Card JVM 16 bemg "sed^ Oae ^^.^^ ^ ^ ^6 and pnxiuces a Java card 

potcntid modification renumbcre the onginal byte codes 60 ycation 12fa stored in the card file system 126 in the 

mto Card JVM 16 byte codes (see FIG. 10). This remim- eEPROM of the integrated circuit card 10. MulUple Java 

bering causes the byte codes 100 in the ongmal byte codes applications 126x, 126y, and 126z can be stored in a 

60 to be modified mto a renumbered byte codes 102. Byte lO ^ ^^^^ ^^^^^ ^ execution 

code ILOAD recogmzed by value 21 may be renumbered to ^^^^^^^ supports commands whereby the terminal 14 

be recognized by vahie 50. This modification may be done ^j^^ j^^^ appUcation to nm immediately, 

for optimizing the type tests (also known in pnor art as Pass „^ ^^^^ ^^^^ 

^ Card JVM 16. The program code fragment ^^^^^ ^3 ^ ^ 

mariced"E m^pendix D shows an iinpiementation of tins 15 command from the loading and execution control 120. 

embodnnent. This modification may done m order o j^^^ ^^^^^j ^^^^^ j^^^ ^^^^ 

reduce the pro-am space required by the Card JVM 16 to ^^^^^.^^ ^ predetermined method (for example, main) of 

interpret the byte code. EssenUally this modificaUoa ^ ^^^^^^ j^^^ ^^^^ application 126z. 

regroups the byte codes mto Card JVM 16 byte codes so that ^^^^ ^^^^^^ j^^^ appUcation 126z 

byte codes with similar operands, results are grouped 20 ^^em 122, which 

together, and there are no gaps betweeD Cari JVM 16 byte ^^^^ capabflities such as VO, EEPROM support, file 

^"''f. ""^ ^"'i JVM 16 to efScentiy check ^ ^ ^^^^ ^^^^^^ ^. 

Card JVM 16 byte codes and validate types as it executes. \. , , * * j • a j- n u* l • 

^ native Java methods as illiistrated m Appendix F which is 

In some embodiments, the card class file converter modi- hereby incorporated by reference, 
fies the original byte codes 60 into a different set of byte ^ sclMcd Java card application 1262 communicates 
codes designed for a different virtual machme architecture, ^ appropriate application in the terminal 14 using the 
as shown m FIG. U. The Java byte code ILOAD 112 communicator 12a to estabhsh a communication channel to 
intended for use on a word stack 114 may be replaced by j^^-^^^ ^^^^ communicator 12a to the 
Card JVM 16 byte code lLOAD_B 116 to be used on a byte tenninal 14 passes through a communicator driver 132 in the 
stack 118. An element in a word stack 114 requires aUocat- tenninal, which is specifically written to handle the com- 
ing 4 bytes of stack space, whereas an element in the byte munications protocol used by the communicator 12a. The 
stack 118 requires only one byte of stack space. Although ^^^^ ^^^^ ^ integrated circuit card driver 134, 
this option may provide an mcrease m execution speed, it ^^-^^ specificaUy written to address the capabilities of the 
risks losing the security features available m the onginal parUcular integrated circuit card 10 being used, and provides 
byte codes. jj^jj i^^^qi software services to the terminal application 136. 

Since tbe previous steps 63, 64 or 66 may have changed jn the preferred embodiment, this driver would be appro- 

the size of the byte codes 60 the card class file converter 26 pn^te PC/SC Smartcard Service Provider (SSP) software, 

has to relink 67 any jumps which have been effected. Since ^tic data then passes to the terminal appUcation 136, which 

the jumps were recorded in the first step 61 of the card class must handle the capabihties provided by the particular card 

file converter 26, this adjustment is carried out by fixing the application 12 6z being run. In this manner, commands and 

jump destinations to their appropriate values. The program responses pass back and forth between the terminal appU- 

code fragment marked "P' in Appendix D shows how these cation 136 and the selected card application 126z, The 

jtmips are fixed. terminal application interacts with the user, receiving com- 

The card class file converter now has modified byte codes 45 mands from the user, some of which are passed to the 

68 that is equivalent to the original byte codes 60 ready for selected Java card application 126z, and receiving responses 

loading. The translation from the Java class file 24a to the &om the Java card application 12 6z, which are processed 

card class file 27 is now complete, and passed back to the user. 

Referring back to FIG. 5, if more class files 24 remain to Referring to FIG. 14, the Card JVM 16 is an interpreter 

be processed 55 the previous steps 51a, 51/?, 51c, 52 and 54 50 that interprets a card application 126j;, The memory 

are repeated for each remaining class file. The card class file resources in the microcontroller that impact the Card JVM 

converter 26 gathers 56 the maps and modified byte codes 16 are the Card ROM 140, Card RAM 141 and the Card 

for the classes 24 that have been processed, places them as EEPROM 142, The Card ROM 140 is used to store the Card 

an aggregate and generates 57 a card class file 27. If JVM 16 and the card operating system 122. Card ROM 140 

required, the card class file converter 26 generates a string 55 may also be used to store fixed card applications 140a and 

to ID output map file 32, that contains a list of all the new class libraries 140^. Loadable applications 141a, 1416 and 

IDs allocated for the strings encountered in the constant pool Ubraries 141c may also be stored in Card RAM 141. The 

42 of the Java class files 24 during the translation. Card JVM 16 inteqjrets a card application 141a, 1416, or 

Referring to FIG. 12, the card loader 28 within the 140a. The Card JVM 16 uses the Card RAM to store the VM 

terminal 14 sends a card class file to the loading and 60 stack 144a and system state variables 1446. The Card JVM 

execution control 120 withm the integrated circuit card 10 16 keeps track of the operations performed via the VM stack 

using standard ISO 7816 commands. The loading and execu- 144a. The objects created by the Card JVM 16 are either on 

tion control 120 with a card operating system 122, which the RAM heap 144c, in the EEPROM heap 146a, or in the 

provides the necessary system resources, including support file system 147. 

for a card file system 124, which can be used to store several 65 All of the heap manipulated by the Card JVM 16 may be 

card applications 126. Many conventional card loaders are stored in the Card RAM 141 as a RAM Heap 144c, or it may 

written in low level languages, supported by the card oper- be distributed across to the Card EEPROM 142 as a 
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EEPROM Heap 146a. Card RAM 141 is also used for method code (subroutine written in the microcontroller's 

recording the state of the system stack 148 that is used by native processor code). In this case, the Card JVM 16 

routines written in the native code of the microcontroller. prepares for an efficient call 163 and return to the native code 

The Card JVM 16 uses the Card EEPROM 142 to store subroutine. The parameters to the native method may be 

application data either in the EEPROM heap 146a or in the s passed on the VM stack 144a or via the System stack 148. 

file system 147. Application data stored in a file may be The appropriate security checks are made and the native 

manipulated via an interface to the card operating system method subroutine is called. On return, the result (if any) of 

122. This interface is provided by a class library 140fj stored the native method subroutine is placed on the VM stack 

in Card ROM 140, by a loadable class library 141c stored in 144a so that it may be accessed by the next byte code to be 

Card EEPROM 142. One such interface is described in lo executed. 

Appendix F. Applications and data in the card are isolated by jhe dispatch loop 164 of the Card JVM 16 is then entered, 

a firewall mechanism 149. The byte code dispatch loop is responsible for preparing, 

To cope with the limited resources available on executing, and retiring each byte code. The loop terminates 

microcontrollers, the Card JVM 16 implements a strict when it finishes interpreting the byte codes in the method 

subset of the Java programming language. Consequently, a ^5 150, or when the Card JVM 16 encounters a resource 

Java application 20 compiles into a class file that contains a limitation or a security violation. 

strict subset of Java byte codes. This enables application [f a previous byte code caused a branch to be taken 165 

programmers to program in this strict subset of Java and still the Card JVM prepares for the branch 165fl. The next byte 

maintain compatibility with existing Java VirUial Machines. code is retrieved 1656. In order to keep the cost of process- 

Thc semantics of the Java byte codes interpreted by the Card ^ ing each byte code down, as many common elements such 

JVM 16 are described in the aforementioned Java Virtual . as the byte code arguments, length, type are extracted and 

Machine Specification. The subset of byte codes interpreted stored. 

by the Card JVM 16 can be found in Appendix C. The card ' ^^^^^ ^^^^ ^^^^^^ ^ ^^^^ ^^^^1 

class file converter 26 checks the Java apphcaUon 20 to the programming language, byte codes in the class file must 

ensure use of only the features available m this subset and 25 ^^^^^^ determined conformant to this model. These 

r ""d'T W ^1 6^ understood and mterpreted by the ^^^^ ^^^^ ^ p^^^ ^ p^^^^^^ 

referred to as the byte code verifier, which operates in four 

In other embodiments, the Card JVM 16 is designed to passes as described in the Java Virtual Machine Specifica- 

interpret a different set or augmented set of byte codes 116. lion. To offer the run-time security that is guaranteed by the 

Although a different byte code set might lead to some byte code verifier, the Card JVM 16 must perform the checks 

performance improvements, departing from a strict Java that perUin to the Pass 3 and Pass 4 of the verifier. This 

subset may not be desirable from the point of view of checking can be bypassed by the Card JVM 16 if it can be 

security that is present in the original Java byte codes or guaranteed (which is almost impossible to do) that the byte 

compatibility with mainstream Java development tools. codes 60 interpreted by the Card JVM 16 are secure. At the 

All Card JVM 16 applications 126 have a defined entry minimum, code security can be maintained as long as object 

point denoted by a class and a method in the class. This entry references cannot be faked and the VM stack 144a and local 

point is mapped in the string to ID input map 30 and variable bounds are observed. This requires checking the 

assigned by the card class file converter 26. Classes, meth- state of the VM stack 144a with respect to the byte code 

ods and fields within a Java application 20 are assigned IDs being executed. 

by the card class file converter 26. For example, the ID xo enforce the security model of the programming 

corresponding to the main application class may be defined language, a 256-byte table is created as shown in Appendix 

as FOOl and the ID corresponding to its main method, such q ^^^^h is hereby incorporated by reference. This table is 

as "mainQV" could be defined as F002. indexed by the byte code number. This table contains the 

The overall execution architecture of the Card JVM is 45 type and length information associated with the indexing 

described by the flowchart in FIG. 15. Execution of the Card byte code. It is encoded with the first 5 bits representing 

JVM 16 begins at the execution control 120, which chooses type, and the last 3 bits representing length. The type and 

a card application 126z to execute. It proceeds by finding length of the byte code is indexed directly from the table by 

and assigning an entry point 152 (a method) in this card the byte code number. This type and length is then used for. 

application for the Card JVM 16 to interpret. The Card JVM jq checking as shown in Appendix H which is hereby incor- 

16 interprets the method 153, If the interpretation proceeds porated by reference. In Appendix H, the checking process 

successfully 154, the Card JVM 16 reports success 155 begins by decoding the length and type from the table in 

returning control back to the execution control 120. If in the Appendix G which is hereby incorporated by reference. The 

course of interpretation 153 the Card JVM 16 encounters an length is used to increment the program counter. The type is 

unhandled error or exception (typically a resource limitation 55 used first for pre-execution checking, to insure that the data 

or a security violation), the Card JVM 16 stops 156 and types on the VM stack 144a are correct for the byte code that 

reports the appropriate error to the terminal 14. is about to be executed. The 256 bytes of ROM for table 

An essential part of the Card JVM 16 is a subroutine that storage allows the original Java byte codes to be mn in the 

handles the execution of the byte codes. This subroutine is Card JVM 16 and minimizes the changes required to the 

described by the flowchart in FIG. 16. Given a method 160 ^^^^ ^° ^® loaded in the card. Additional Java byte 

it executes the byte codes in this method. The subroutine codes can be easily supported since it is relatively easy to 

starts by preparing for the parameters of this method 161. update the appropriate table entries. 

This involves setting the VM stack 144fl pointer, VM stack in other embodiments, as shown in FIG. 10, the Java byte 

144a frame limits, and setting the program counter to the codes in the method are renumbered in such a manner that 

first byte code of the method. 55 the byte code type and length information stored in the table 

Next, the method flags are checked 162. If the method is in Appendix H is implicit in the reordering. Appendix H is 

flagged native, then the method is actually a caU to native hereby incorporated by reference. Consequently, the checks 
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that must be performed on the state of the VM stack 144a 
and the byte code being processed does not have to involve 
a tabic look up. The checks can be performed by set of 
simple comparisons as shown in Appendix 1 which is hereby 
incorporated by reference. This embodiment is preferable 
when ROM space is at a premium, since it eliminates a 
256-byte table. However adding new byte codes to the set of 
supported byte codes has to be carefully thought out since 
the new byte codes have to &t in the implicit numbering 
scheme of the supported byte codes. 

In another embodiment, the Card JVM 16 diooses not to 
perform any security chedcs in favor of Card JVM 16 
execution speed. This is illustrated in the flowchart in FIG. 
18. The flow chart in FIG. 18 is the same as that of FIG. 16 
with the security checks removed. This option is not desir- 
able from the point of view of security, unless it can be 
guaranteed that the byte codes are secure. 

The Card JVM 16 may enforce other security checks as 
well. If the byte code may reference a local variable, the 
Card JVM 16 checks if this reference is valid, throwing an 
error if it is not. If the reference is valid, the Card JVM 16 
stores the type of the local variable for future checking. The 
VM stack 144a pointer is checked to see if it is still in a valid 
range. If not an exception is thrown. The byte cede number 
is checked. If it is not supported, an exception is thrown. 

Finally, the byte code itself is dispatched X6Sd. The byte 
codes translated by the Card JVM 16 are Usted in Appendix 
C. The semantics of the byte codes are described in the 
aforementioned Java Virtual Machine Specification with 
regard to the state of the VM stack 144a before and after the 
dispatch of the byte code. Note also that some byte codes 
(the byte codes, INVOKESTARC, INVOKESPECIAL, 
INVOKENONVIRTUAL and INVOKEVIRTUAL) may 
cause reentry into the Card JVM 16, requiring processing to 
begin at the entry of the subroutine 161. FIG. 17 shows the 
flowchart of the byte code execution routine. The routine is 
given a byte code 171 to execute. The Card JVM 16 executes 
172 the instructions required for the byte code. If in the 
course of executing the Card JVM 16 encounters a resource 
Umitation 173, it returns an error 156. This error is returned 
to the terminal 16 by the Card JVM 16. If the byte code 
executes successfuUy, it returns a success 175. 

After execution, the type of the resuU is used to set the 
VM stack 144a slate correctly 165e, properly flagging the 
data types on the VM stack 144a. The byte code information 
gathered previously 1656 from the byte code info table is 
used to set the state of the VM stack 144a in accordance with 
the byte code that just executed. 

In other embodiments, setting the output state of the VM 
stack 144a with respect to the byte code executed is sim- 
phfied if the byte code is renxmibered. This is shown in 
Appendix I which is hereby incorporated by reference. 

In yet another embodiment, the Card JVM 16 may bypass 
setting the output state of the VM stack 144a in favor of 
Card JVM 16 execution speed. This option is not desirable 
from the point of view of security, unless it can be guaran- 
teed that the byte codes are secure. 

After the byte code has been executed, the byte code is 
retired 165/. This involves popping arguments off the VM 
stack 144a. Once byte code processing is completed, the 
loop 164 is repeated for the next byte code for the method. 

Once the dispatch loop 164 terminates, the VM stack 
144a is emptied 166. This prevents any object references 
filtering down to other Card JVM 16 invocations and 
breaking the Card JVM's 16 security. Termination 167 of the 
byte code dispatch loop 164 indicates that the Card JVM 16 
has completed executing the requested method. 
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To isolate data and applications in the integrated circuit 
card 10 from each other, the integrated circuit card 10 relies 
on the firewall mechanism 149 provided by the Card JVM 
16. Because the Card JVM implements the standard pass 3 
and pass 4 verifier checks, it detects any attempt by an 
application to reference the data or code space used by 
another application, and flag a security error 156. For 
example, conventional low level applications can cast non- 
reference data types into references, thereby enabling access 
to unauthorized memory space, and violating security. With 
this invention, such an attempt by a card apphcation 126z to 
use a non-reference data type as a reference will trigger a 
security violation 156. In conventional Java, this protected 
application environment is referred to as the sandbox 
application-interpretation environment. 

However, these firewall faciUties do not work indepen- 
dently. In fact, the facilities are overlapping and mutually 
reinforcing with conventional access control lists and 
encryption mechanisms shown in the following table: 
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Taken together, these facilities isolate both data and 
appUcations on the integrated circuit card 10 and ensure that 
each card application 126 can access only the authorized 
resources of the integrated circuit card 10. 

Referring to FIG. 19, card applications 126x, 126>', 12 6z 
can be endowed with specific privileges when the card 
applications 126 execute. These privileges determine, for 
example, which data files the card applications 126 can 
access and what operations the card appUcations 126 can 
perform on the file system 147. The privileges granted to the 
card applications 126 are normally set at the time that a 
particular card application 126z is started by the user, 
typically from the terminal 14. 

The integrated circuit card 10 uses cryptographic identi- 
fication verification methods to associate an identity 190 
(e.g., identities 190a, 190b and 190c) and hence, a set of 
privileges to the execution of the card apphcation 126. The 
association of the specific identity 190c to the card appli- 
cation 126z is made when the card application 126z begins 
execution, thus creating a specific running application 200, 
as shown in FIG. 20. The identity 190 is a unique legible text 
string reliably associated with an identity token. The identity 
token (e.g., a personal identification number (PIN) or a RSA 
private key) is an encryption key. 

Referring to FIG. 20, in order to run a specific card 
apphcation 126z, the identity 190c of the card apphcation 
126z must be authenticated. The identity 190c is authenti- 
cated by demonstrating knowledge of the identity token 
associated with the identity 190c. Therefore, in order to run 
the card application 126z, an agent (e.g., a card holder or 
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another application wishing to run the application) must tion is accomplished by including in the identity authenti- 

show that it possesses or knows the application's identity- cation process the exchange of a one-time session key 209 

defining encryption key. between the a card application 1262 and the terminal appli- 

One way to demonstrate possession of an encryption key cation 136. The key 209 is then used to encrypt subsequent 

is simply to expose the key itself. PIN verification is an 5 traffic between the authenticating terminal application 136 

example of this form of authentication. Another way to and authenticated card application 126z. Given the 

demonstrate the possession of an encryption key without one-lime session key 209, a rogue terminal application can 

actually exposing the key itself is to show the ability to neither "listen in" on an authenticated communication 

encrypt or decrypt plain text with the key. between the terminal 14 and the integrated circuit card 10, 

Thus, a specific rumiing application 200 on the integrated nor can the rogue terminal applicadon "spoof" the card 

circuit card 10 includes a card application 126z plus an 'PK''^^" "'^ performmg unauthorized operations on its 

authenticated identity 190c. No card application 126 can be Dcoail. . ^ . , «- , 

run without both of these elements being in place. TTie card ^ ^^^P^"" '•ecryption of card/tennmal lraffic can be 

applicaUon 1262 defines data processing operations to be '^^'^ed either by the card operaUng system 122 or by the 

performed, and the authenticated idenUty 190c determines « card application itself 126z In the former case the commu- 

on what computational objects those operations may be ■""'^o" «f.™'?»l " ''^'"S «°'='yPted transpar- 

performed. For example, a specific appUcation 126z can '"'"y '° the application, and message traffic arnyes 

only access identity C's flies 202 in the file system 147 decrypted m the dau space of the apphcation. In the latter 

associated with the specific idenUty 190c. and the specific applicatton 126z elects to perform encrypUon 

card application 1262 cannot access other files 204 that are « and decryption to provide an extra layer of secunty smce the 

associated with identities other than the specific identity applj^aUon could encrypt data as soon as it was created and 

jp(j^ would deaypt data only when it was about to be used. 

_ . J • • j<« , jj- • , . . Otherwise, the data would remain encrypted with the session 

The integrated circuit card 10 may take additional steps to 209 

ensure appUcation and data isolation. TTie integrated circuit „ ^ " ^^^^00 firewall includes three mutually 

card 10 furnishes three software features sets: authenticated- .^j^^, ^^ts. Data files are protected by 

Identity access control lists; a Java-based virtual machine; authenticated-identily access control lists. Application 

and one-time session encryption keys to protect data files, ^e^ution spaces are protected by the Card JVM 16. Com- 

app ication execuUon, and communicaUon channels, respec- ^^^^^tion channels are protected with one-time session 

lively. CollecUvely, for one embodiment, these features sets encryption keys 209 

provide the application data firewalls 149 for one embodi- ^^^^ embodiments, the above-described techniques are 

ment. The foUowing discusses each software feature set and ^ microcontroller (such as the processor 12) may 

then shows how the three sets work together to insure ^^^^^ ^^^.^^ automobile engine) other 

application and data isolation on the integrated circuit card ^ ^^^^^^^ ^^^.^ applications, the 

35 microcontroller provides a small platform (i.e., a central 

An access control list (ACL) is associated with every processing unit, and a memory, both cf which are located on 

computational object (e.g., a data file or a commumcation ^ semiconductor substrate) for storing and execuUng high 

channel) on the integrated circuit card 10 thai is be i^^^i programming languages. Most existing devices and 

protected, i.e., to which access is to be .controlled. An entry designs that utilize a microcontroUer could use this 

on an ACL (for a particular computational object) is in a data invention to provide the ability to program the microcon- 

format referred to as an e-tuple: troller using a high level language, and appUcation of this 

typ6:ideQtity:permissions invention to such devices is specifically included. 

The type field indicates the type of the following identity (in The term application inchides any program, such as Java 

the identity field), e.g., a user (e.g., "John Smith"), or a applications, Java applets, Java aglets, Java servlets, Java 

group. The permissions field indicates a list of operations 45 commlets, Java components, and other non-Java programs 

(e.g., read, append and update) that can be performed by the that can result in class files as described below, 

identity on the computational object. Class files may have a source other than Java program 

As an example, for a data file that has the ACL entry: files. Several programming languages other than Java also 

USER: AcmeAir lines: RAU, have compilers or assemblers for generating class files firom 

any application whose identity is "AcmeAirlines" can read 50 their respective source files. For example, the programming 

("R"), append ("A*') and update ("U") the data file. Id language Eiffel can be used to generate class files using 

addition, the ACL may be used selectively to permit the Pirmin Kalberer's "J-Eiffel", an Eiffel compiler with JVM 

creation and deletion of data files. Furthermore, the ACL byte code generation (web site: http://www.spin.ch/ 

may be used selectively to permit execution of an applica- -kalberer^ive/index.htm). An Ada 95 to Java byte code 

tion. 55 translator is described in the following reference 

Whenever a computational object is accessed by a run- (incorporated herein by reference): Taft, S. Ibcker, "Pro- 

ning application 200, the access is intercepted by the Card gramming the lotemet in Ada 95**, proceedings of Ada 

JVM 16 and passed to the card operating system 122, which Europe *96, 1996. Jasmin is a Java byte code assembler that 

determines if there is an ACL associated with the object. If can be used to generate class files, as described in the 

there is an associated ACL, then the identity 190c associated 60 following reference (incorporated herein by reference): 

with the running application 200 is matched on the ACL. If Meyer, Jon and Troy Downing, "Java Virtual Machine", 

the identity is not found or if the identity is not pennitted for O'Reilly, 1997. Regardless of the source of the class files, 

the type of access that is being requested, then the access is the above description applies to languages other than Java to 

denied. Otherwise, the access is flowed to proceed. generate codes to be interpreted. 

Referring to FIG. 13, to prevent the potential problems 65 FIG. 21 shows an integrated circuit card, or smart card, 

due to the single data path between the integrated circuit which includes a microcontroller 210 that is mounted to a 

card 10 and the terminal 14, communication channel isola- plastic card 212. The plastic card 212 has approximately the 
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same form factor as a typical credit card. The communicator 2, The integrated circuit card of claim 1, wherein the high 

12a can use a contact pad 214 to establish a communicatioo level programming language format comprises a class file 

channel, or the communicator 12fl can use a wireless com- format. 

municalion sysietn. 3. The integrated circuit card of claim 1 wherein the 

In other embodiments, a microcontroller 210 is mounted 5 processor comprises a microcontroller, 

into a mobile or fixed telephone 220, effectively adding 4^ xhe integrated circuit card of claim 1 wherein at least 

smart card capabilities to the telephone, as shown in FIG. 22. ^ portion of the memory is located in the processor. 

In these embodiments, the microcontroller 210 is mounted 5^ integrated circuit card of claim 1 wherein the high 

on a module (such as a Subscriber Identity Module (SIM)), j^vel programming language format comprises a Java pro- 

for insertion and removal from the telephone 220. gramming language format. 

In other embodiments, a microcontroller 210 is added to 5 -j^^ integrated circuit card of claim 1, wherein 

a key ring 230 as shown in FIG. 23. This can be used to appUcation has been processed from a second appli- 

sccure access to an automobile that is equipped to recognize ^^^^ ^^^^ ^ ^^^^^^^^ 1^^^ 

kc (j''^'*'^'^'^ microcontroUer 210 on the ^eing a string of characters, and 

^ T ^? u *u -^An 1 u wherein in the first application the siring of characters is 

Jewelry such as a watch or rmg 240 can also house a 1 j -.l j .ve 

•^^ -^rt • • u • replaced with an identifier. 

mcrocontroUer 210 m an ergonomic maimer, as shown m ^ ^j^^, ^^^^ ^ ^^^.^ 

FIG. 24. Such embodiments typically use a wireless com- j • 

. . . - . ui- u- • identifier compnscs an integer 

munication system for establishing a communication o -ru • * * ^ - -T a e ^ - * u • .u 

...•^ t i. 8. The mtegrated cuciut card of claim 1 wherem the 

channel, and are a convement way to implement access . ^ n , ^ 

.... . . f L 1 / *L ^ processor is further configured to: 

control with a mmunum of hassle to the user. ^ . _ * ^ r 

HG. 25 illustrates a microcontroller 210 mounted in an ^^^f ^ j;^^^*^^^ ^^"^ ^ requester to access an element of 

electrical subsystem 252 of an automobile 254. In this ' 

embodiment, the microcontroUer is used for a variety of ^fter receipt of the request, interact with the requester to 

purposes, such as to controlling access to the automobile, ^ authenUcate an identity of the requester; and 

(e.g. chedting identity or sobriety before enabling the igni- based on the identity, selectively grant access to the 

tion system of the automobile), paying tolls via wireless element, 

communication, or interfacing with a global positioning integrated circuit card of claim 8, wherein the 

system (GPS) to track the location of the automobile, to requester comprises the processor. 

name a few. 3q l^* The integrated circuit card of claim 8, wherein the 

While specific embodiments of the present invention have requester comprises the terminal, 

been described, various modifications and substitutions will The integrated circuit card of claim 8, wherein 

become apparent to one skilled in the art by this disclosure. the element comprises the application stored in the 

Such modifications and substitutions are within the scope of memory, and 

the present invention, and are intended to be covered by the 35 once access is allowed, the requester is configured to use 

appended claims. the applicatioa 

What is claimed is: 12. The integrated circuit card of claim 8, wherein 

1. An integrated circuit card for use with a terminal, the element comprises another apphcation stored in the 

comprising: memory. 

a communicator configured to commtmicate with the 4q 13. The integrated circuit card of claim 8, wherein the 

terminal; element includes data stored in the memory, 

a memory storing: 14. The integrated circuit card of claim 8 wherein the 

an application derived from a program written in a high element comprises the commimicator. 

level programming language format wherein the 15. Hie integrated circuit card of claim 8, wherein the 

application is derived from a program written in a 45 memory also stores an access control list for the element, the 

high level programming language format by first access control list furnishing an indication of types of access 

compiling the program into a compiled form and to be granted to the identity, the processor farther configured 

then converting the compiled form into a converted to: 

form, the converting step including at least one step based on the access control list, selectively grant specific 

selected from a group consisting of 50 types of access to the requester. 

recording all jumps and their destinations in the 16. The integrated circuit card of claim 15 wherein the 

original byte codes; types of access include reading data, 

converting specific byte codes into equivalent 17. The integrated circuit card of claim 15 wherein the 

generic byte codes or vice-versa; types of access include writing data, 

modifying byte code operands from references using ss 18. The integrated circuit card of claim 15 wherein the 

identifying strings to references using unique types of access include appending data, 

identifiers; and 19. The integrated circuit card of claim 15 wherein the 

renumbering byte codes in a compiled format to types of access include creating data, 

equivalent byte codes in a format suitable for 20. The integrated circuit card of claim 15 wherein the 

interpretation; and 60 types of access include deleting data, 

an interpreter operable to interpret such an application 21. The integrated circuit card of claim 15 wherein the 

derived from a program written in a high level types of access include executing an application, 

programming language format; and 22. The integrated circuit card of claim 1, wherein the 

a processor coupled to the memory, the processor con- apphcation is one of a plurality of applications stored in the 

figured to use the interpreter to interpret the application 65 memory, the processor is further configured to: 

for execution and to use the communicator to commu- receive a request from a requester to access one of the 

nicate with the terminal. plurality of applications; 
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after receipt of the request, determine whether said one of renumbering byte codes in a compiled format to 
the plurality of applications complies with a predeter- equivalent byte codes in a format suitable for inter- 
mined set of rules; and pretation; and 

based on the determination, selectively grant access to the using a processor of the integrated circuit card to use the 

requester to said one of the plurality of applications. ^ interpreter to interpret the application for execution; 

23. The integrated circuit card of claim 22, wherein the and 

predetermined rules provide a guide for determining using a communicator of the card when communicating 

whether said one of the plurality of applications accesses a between the processor and the terminal 

predetermined rcgioa of the memory. 32. The method of claim 31, wherein the high level 

24. The integrated circuit card of claim 22, wherein the 10 programming language format comprises a class file format, 
processor is further configured to: 33. The method of claim 31, wherein the processor 

authenticate an identity of the requester; and comprises a microcoatroller. 

grant access to said one of the plurality of applications 34. The method of claim 31, wherein at least a portion of 

based on the identity, the memory is located in the processor. 

25. The integrated circuit card of claim 1, wherein the 35, The method of claim 31, wherein the high level 
processor is further configured to: programming language format comprises a Java program- 
interact with the terminal via the communicator to authen- ™i°g language format. 

ticate an identity; and 36. The method of claim 31, wherein 

determine if the ideotity has been authenticated; and Ihc application has been processed from a second appli- 

based on the determination, selectively aUow communi- cation having a pluraHty of program elements, at least 

cation between the terminal and the integrated circuit one being a string of characters, further comprising: 

replacing the string of characters in the first application 

26. The integrated circuit card of claim 25, wherein the identifier. 

communicator and the terminal communicate via coramu- ^ . ^7. The method of claim 36, wherein the identifier 

nication channels, the processor further configured to assign inchides an integer. 

one of the communication channels to the identity when the ^8. The method of claim 31, further comprising: 

processor allows the communication between the terminal receiving a request from a requester to access an element 

and the integrated circuit card. of the card; 

27. The integrated circuit card of claim 26, wherein the 30 after receipt of the request, interacting with the requester 
processor is further configured to: to authenticate an identity of the requester; and 

assign a session key to said one of the communication based on the identity, selectively granting access to the 

channels, and clement, 

use the session key when the processor and the tenminal 39, The method of claim 38, wherein the requester com- 

communicate via said one of the communication chan- 35 prises the processor. 

nels. 40. The method of claim 38, wherein the requester com- 

28. The integrated circuit card of claim 1, wherein the prises the terminal, 

terminal has a card reader and the communicator comprises 41, The method of claim 38, wherein the element com- 

a contact for communicating with the card reader. prises the application stored in the memory, further com- 

29. The integrated circuit card of claim 1, wherein the 40 prising: 

terminal has a wireless communication device and the once access is allowed, using the application with the 

communicator a wireless transceiver for communicating requester. 

with the wireless communication device. 42. The method of claim 38, wherein the element com- 

30. The integrated circuit card of claim 1, wherein the prises another application stored in the memory, 
terminal has a wireless communication device and the 45 43. The method of claim 38, wherein the element includes 
communicator comprises a wireless transmitter for commu- data stored in the memory. 

nicating with the wireless communication device. 44. The method of claim 38, wherein the element com- 

31. A method for use with an integrated circuit card and prises the communicator. 

a terminal, comprising: 45. The method of claim 38, wherein the memory also 

storing an interpreter operable to interpret programs 50 stores an access control list for the element, the access 

derived from programs written in a high level program- control list furnishing an indication of types of access to be 

ming language and an application derived firom a granted to the identity, further comprising: 

program written in a high level programming language based on the access control list, using the processor to 

format in a memory of the integrated circuit card selectively grant specific types of access to the 

wherein the application is derived from a program 55 requester. 

written in a high level programming language format 46. TTie method of claim 45, wherein the types of access 

by first compiling the program into a compiled form include reading data, 

and then converting the compiled form into a converted 47. The method of claim 45, wherein the types of access 

form, the converting step including at least one step include writing data, 

selected from a group consisting of 60 48. The method of claim 45, wherein the types of access 

recording all jumps and their desdnations in the origi- include appending data. 

nal byte codes; 49. The method of claim 45, wherein the types of access 

converting specific byte codes into equivalent generic include creating data. 

byte codes or vice -versa; 50. The method of claim 45, wherein the types of access 

modifying byte code operands from references using 65 include deleting data. 

identifying strings to references using unique iden- 51. The method of claim 45, wherein the types of access 

tifiers; and including executing an application. 
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52. The method of claim 31, whereia the application is 
one of a plurality of applications stored in the memory, 
further comprising: 

receiving a request &om a requester to access one of the 
applications stored in (he memory; 

upon receipt of the request, determining whether said one 
of the plurality of applications complies with a prede- 
termined set of rules; and 

based on the determining, selectively granting access to 
the said one of the plurality of applications. 

53. The method of claim 52, wherein the predetermined 
rules provide a guide for determining whether said one of the 
plurality of applications accesses a predetermined region of 
the memory. 

54. The method of claim 52, further comprising: 
authenticating an indentity of the requester; and 

based on the indentity, granting access to said one of the 
plurality of applications. 

55. The method of claim 31, further comprising: 
communicating with the terminal to authenticate an iden- 
tity; 

determining if the identity has been authenticated; and 
based on the determining, selectively allowing commu- 
nication between the terminal and the integrated circuit 
card. 

56. The method of claim 55, further comprising: 
communicating between the terminal and the processor 

via communication channels; and 
assigning one of the communication channels to the 
identity when the allowing allows communication 
between the card reader and the integrated circuit card. 

57. The method of claim 56, further comprising: 
assigning a session key to said one of the communication 

channels; and 

using the session key when the processor and the terminal 
communicate via said one of the communication chan- 
nels. 

58. A microcontroller comprising; 
a memory storing: 

a derivative application derived from an application 
having a class file format wherein the application is 
derived from an application having a class file format 
by first compiling the application having a class file 
format into a compiled form and then converting the 
compiled form into a converted form, the converting 
step including at least one step selected from a group 
consisting of 

recording all jumps and their destinations in the origi- 
nal byte codes; 

converting specific byte codes into equivalent generic 
byte codes or vice-versa; 

modifying byte code operands from references using 
identifying strings to references using unique iden- 
tifiers; and 

renumbering byte codes in a compiled format to 

equivalent byte codes in a format suitable for 

interpretation, and 
an interpreter configured to interpret applications 

derived from applications having a class file format; 

and 

a processor coupled to the memory, the processor con- 
figured to use the interpreter to interpret the derivative 
application for execution. 

59. The microcontroller of claim 58, further comprising: 
a communicator configured to communicate with a ter- 
minal. 
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60. The microcontroller of claim 59, wherein the terminal 
has a card reader and the communicator comprises a contact 
for communicating with the card reader. 

61. The microcontroller of claim 59, wherein the terminal 
has a wireless communicator and a wireless transceiver for 
communicating with the wireless communication device. 

62. The microcontroller of claim 59, wherein the terminal 
has a wireless communication device and the communicator 
comprises a wireless transmitter for commtmicating with the 
wireless communication device. 

63. The microcontroller of claim 58, >\^erein the class file 
format comprises a Java class file format. 

64. An integrated circuit card for use with a terminal, 
comprising: 

a communicator configured to communicate with the 
terminal; 

a memory storing: 
applications, each application derived from applica- 
tions having a high level programming language 
format, and 

an interpreter operable to interpret applications derived 
from apphcations having a high level programming 
language format wherein the appUcation is derived 
from a program written in a high level programming 
language format by first compiling the program into 
a compiled form and then converting the compiled 
form into a converted form, the converting step 
including at least one step selected from a group 
consisting of 

recording all jumps and their destinations in the 

original byte codes; 
converting specific byte codes into equivalent 

generic byte codes or vice-versa; 
modifying byte code operands from references using 

identifying strings to references using unique 

identifiers; and 
renumbering byte codes in a compiled format to 

equivalent byte codes in a format suitable for 

interpretation; and 
a processor coupled to the memory, the processor con- 
figured to: 

a. ) use the interpreter to interpret the applications for 
execution, 

b. ) use the interpreter to create a firewall to isolate the 
applications from each other, and 

c. ) use the communicator to commimicate with the 
terminal. 

65. A microcontroller having a set of resource constraints 
and comprising: 

a memory, and 

an interpreter loaded in memory and operable within the 
set of resource constraints, the microcontroller having: 
at least one application loaded in the memory to be 
interpreted by the interpreter, wherein the at least one 
application is generated by a programming environ- 
ment comprising: 

a) a compiler for compiling application source pro- 
grams written in high level language source code 
form into a compiled form, and 

b) a converter for post processing the compiled form 
into a minimized form suitable for interpretation 
within the set of resource constraints by the 
interpreter, wherein the converter comprises means 
for translating from the byte codes in the compiled 
form to byte codes in a format suitable for interpre- 
tation by the interpreter by: 
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a) using ai least one step in a process including the 
steps: 

a.l) recording all jumps ^ad their destinations in 
the originaJ byte codes; 

a. 2) converting specific byte codes into equiva- 
lent generic byte codes or vice-versa; 

a.3) modifying byte code operands from refer- 
ences using identifying strings to references 
using unique identifiers; and 

a.4) renumbering byte codes in the compiled 
form to equivalent byte codes in the format 
suitable for interpretation; and 

b) relinking jumps for which destination address is 
effected by conversion step a.l, a.2, a.3, or a.4. 

66. The microcontroller of claim 65, wherein the com- 
piled form includes attributes, and the converter comprises 
a means for including attributes required by the interpreter 
while not including the attributes not required by the inter- 
preter. 

67. The microcontroller of claim 65 wherein the compiled 
form is in a standard Java class file format and the converter 
accepts as input the compiled form in the standard Java class 
file format and produces output in a form suitable for 
interpretation by the interpreter. 

68. The microcontroller of claim 65 wherein the compiled 
form includes associating an identifying string for objects, 
classes, fields, or methods, and the converter comprises a 
means for mapping such strings to unique identifiers. 

69. The microcontroller of claim 68 wherein each unique 
identifier is an integer. 

70. The microcontroller of claim 68 wherein the mapping 
of strings to unique identifiers is stored in a string to 
identifier map file. 

71. The microcontroller of claim 65 where in the high 
level language supports a first set of features and a first set 
of data types and the interpreter supports a subset of the first 
set of features and a subset of the first set of data types, and 
wherein the converter verifies that the compiled form only 
contains features in the subset of the first set of features and 
only contains data types in the subset of the first set of data 
types. 

72. The microcontroller of claim 65 wherein the apphca- 
tion program is compiled into a compiled form for which 
resources required to execute or interpret the compiled form 
exceed those available on the microcontroller. 

73. The microcontroller of claim 65 wherein the compiled 
form is designed for portabiUty on dififerent computer plat- 
forms. 

74. The microcontroller of claim 65 wherein the inter- 
preter is further configured to determine, during an inter- 
pretation of an application, whether the application meets a 
security criteria selected from a set of rules containing at 
least one rule selected from the set: 

not allowing the application access to unauthorized por- 
tions of memory, 

not allowing the application access to unauthorized 
microcontroller resources, 

wherein the application is composed of byte codes and 
checking a plurality of byte codes at least once prior to 
execution to verify that execution of the byte codes 
docs not violate a security constraint. 

75. The microcontroller of claim 65 wherein at least one 
application program is generated by a process including the 
steps of: 

prior to loading the application verifying that the appfi- 

cation docs not violate any security constraints; and 
loading the application in a secure manner. 
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76. The microcontroller of claim 75 >^^erein the step of 
loading in a secure matmer comprises the step of: 

verifying that the loading identity has permission to load 
applications onto the microcontroller. 

77. The microcontroller of claim 75 wherein the step of 
loading in a secure manner comprises the step of: 

encrypting the application to be loaded using a loading 
key. 

78. A method of programming a microcontroller having a 
memory and a processor operating according to a set of 
resource constraints, the method comprising the steps of: 

inputting an application program in a first programming 
language; 

compiling the appfication program in the first program- 
ming language into a first intermediate code associated 
with the first programming language, wherein the first 
intermediate code being interpretable by at least one 
first intermediate code virmal machine; 

converting the first intermediate code into a second inter- 
mediate code, wherein the step of converting com- 
prises: 

at least one of the steps of: 

a) recording all jumps and their destinations in the 
original byte codes; 

b) converting specific byte codes into equivalent 
generic byte codes or vice-versa; 

c) modifying byte code operands from references 
using identifying strings to references tising 
unique identifiers; and 

d) renmnbering byte codes in a compiled format to 
equivalent byte codes in a format suitable for 
interpretation; and 

relinking jumps for which destination address is effected 

by conversion step a), b), c), or d); 
wherein the second intermediate code is interpretable 

within the set of resource constraints by at least one 

second intermediate code virtual machine; and 
loading the second intermediate code into the memory of 

the microcontroller. 

79. The method of programming a microcontroller of 
claim 78 wherein the step of converting further comprises: 

associating an identifying string for objects, classes, 

fields, or methods; and 
mapping such strings to unique identifiers. 

80. The method of claim 79 wherein the step of mapping 
comprises the step of mapping strings to integers. 

81. The method of claim 80 wherein the step of loading 
the second intermediate code into the memory of the micro- 
controller further comprises checking the second interme- 
diate code prior to loading the second intermediate code to 
verify that the second intermediate code meets a predefined 
integrity check and that loading is performed according to a 
security protocol. 

82. The method of claim 81 wherein the security protocol 
requires that a particular identity must be validated to permit 
loading prior to the loading of the second intermediate code. 

83. The method of claim 81 further characterized by 
providing a decryption key and wherein the security proto- 
col requires that the second intermediate code is encrypted 
using a loading key corresponding to the decryption key. 

84. An integrated circuit card for use with a terminal, 
comprising: 

a communicator configured to communicate with the 

terminal; 
a memory storing: 
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an application denved &om a program written in a high 
level programming language format wherein the 
application is derived from a program written in a 
high level programming language format by first 
compiling the program into a compiled form and 
then converting the compiled form into a converted 
form, the converting step including the steps of: 
modifying byte code operands from references using 

identifying strings to references tising unique 

identifiers; 

recording all jumps and their destinations in the 

original byte codes; 
converting specific byte codes into equivalent 

generic byte codes or vice-versa; and 
renumbering byte codes in a compiled format to 
equivalent byte codes in a format suitable for 
interpretation; and 
an interpreter operable to interpret such an applica- 
tion derived from a program written in a hi^ level 
programming language format; and 
a processor coupled to the memory, the processor con- 
figured to use the interpreter to interpret the application 
for execution and to use the communicator to commu- 
nicate with the terminal. 

85. A method for use with an integrated circuit card and ^ 
a terminal, comprising: 

storing an interpreter operable to interpret programs 
derived from programs written in a high level program- 
ming language and an application derived from a 
program written in a high level programming language 
format in a memory of the integrated circuit card 
wherein the application is derived from a program 
written in a high level programming language format 
by first compiling the program into a compiled form 
and then converting the compiled form into a converted 
form, the converting step including: 
modifying byte code operands from references tising 
ideatifying strings to references using unique iden- 
tifiers; 

recording all jimips and their destinations in the origi- 
nal byte codes; 

converting specific byte codes into equivalent generic 
byte codes or vice-versa; and 

renumbering byte codes in a compiled format to 
equivalent byte codes in a format suitable for inter- 
pretation; 

using a processor of the integrated circuit card to use the 
interpreter to interpret the application for execution; 
and 

using a communicator of the card when communicating 
between the processor and the terminal. 

86. An integrated circuit card for use with a terminal, 
comprising: 

a communicator configured to commtmicate with the 
terminal; 
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a memory storing: 
applications, each application derived from applica- 
tions having a high level programming language 
format, and 

an interpreter operable to interpret applications 
derived from applications having a high level 
programming language format wherein the appli- 
cation is derived from a program written in a high 
level programming language format by first com- 
piling the program into a compiled form and then 
converting the compiled form into a converted 
form, the converting step including the steps of: 
modifying byte code operands from references 

using identifying strings to references using 

unique identifiers; 
recording all jumps and their destinations in the 

original byte codes; 
converting specific byte codes into equivalent 

generic byte codes or vice-versa; and 
renumbering byte codes in a compiled format to 

equivalent byte codes in a format suitable for 

interpretation; and 
a processor coupled to the memory, the processor con- 
figured to: 

a. ) use the interpreter to interpret the applications for 
execution, 

b. ) use the interpreter to create a firewall to isolate the 
applications from each other, and 

c. ) use the communicator to communicate with the 

terminal. 
87. A microcontroller comprising: 
a memory storing: 

a derivative application derived from an application hav- 
ing a class file format wherein the application is derived 
from an application having a class file format by first 
compiling the application having a class file format into 
a compiled form and then converting the compiled 
form into a converted form, the converting step includ- 
ing: 

recording all jumps and their destinations in the origi- 
nal byte codes; 

converting specific byte codes into equivalent generic 
byte codes or vice-versa; and 

renumbering byte codes in a compiled format to 
equivalent byte codes in a format suitable for 
interpretation, and 

an interpreter configured to interpret applications 
derived from applications having a class file format; 
and 

a processor coupled to the memory, the processor con- 
figured to use the interpreter to interpret the derivative 
application for execution. 
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